Update 6/26/2020: Since this blog post went live, AMP has officially graduated from the OpenJS Foundation Incubation Program. See the news here.
This summer marks five years since the first line of code for AMP was written. The project has evolved, impacted by things like the dynamic nature of the web, changing user expectations, ideas and code contributions from the ecosystem, and more. We’ve listened carefully to publishers and the developer community, and have constantly iterated AMP in response to their feedback.
With the support of the AMP community, we have aimed to live up to our mission of providing a content format that puts users first, and in doing so, helps support the success of every publisher, merchant, and advertiser on the web. With a half-decade of experience and many insights gained, we’re looking back at the origins of the project, lessons learned along the way, and what might lie in the future for AMP.
The beginnings: A swiftly changing web and a fortuitous conversation
Before I was even a software engineer at Google, the web was beginning to grapple with its future, famously captured by Wired in its “The Web Is Dead” feature. Today, the web has evolved and continues to thrive, but in 2010 this article held more than a grain of truth. With the rise of mobile devices, apps and social platforms, many industries, news publishers in particular, were seeing a dramatic shift in consumer behavior, and the web was struggling to keep up.
Web publishers faced incredible challenges in offering compelling mobile experiences – at the time, mobile web pages took an average of 19 seconds to open. Publishers had to not only learn how to design content for mobile, but also how to evolve their business model. The simultaneous rise of social platforms increased demands on publisher time as their focus was split between developing for the web and social.
To address these challenges and changing user expectations on mobile, new content consumption formats emerged on news and social media platforms. These formats provided users a quicker way to access news with consistent user experience, but these formats were limited only to the platforms they were developed for. They also raised questions for publishers related to business model control and branding.
In the Spring of 2015, over a hundred journalists and technologists from around the world convened for Newsgeist Europe in Helsinki, an annual event hosted by Google to discuss the future of the news industry. As was traditional for Newsgeist, attendees proposed sessions, one of which posed the question: “What could Google do for news?” The resulting session focused on content distribution in light of the new proprietary news and social content formats, developed in part to tackle publishers’ growing UX challenges.
During the conversation, news publishers expressed the need for a new potential open source approach for distributed content; it was initially referred to as a “portable content unit.” The idea was this “unit” could help meet increasing opportunities for syndicating content with a great user experience while maintaining publisher control over business model, branding, and presentation. Publishers also indicated that a new, open-source approach might encourage a greater degree of collaboration around a single format.
Shortly after Newsgeist, David Besbris, a VP of engineering in Google Search, started assembling a product team which I joined and we began early discussions about building the new distributed content format, which we officially started to refer to as Portable Content Unit (PCU). Early on, our team focused on engaging with publishers in order to deeply understand their industry’s needs. We kept asking ourselves the question that had started these conversations in the first place: “What could Google do for news?”
Our early conversations with publishers, starting with our Digital News Initiative Product Working Group, brought us to believe that a holistic solution that addresses both mobile experience design and performance could be a powerful option for publishers faced with a growing landscape of new content distribution opportunities. We extended this collaboration globally with discussions and planning sessions with publishers around the world. With this realization, we had a mission. We saw how critical it was for the news industry to improve web performance on mobile devices, and we got to work on making the PCU a reality.
The early design of this project was driven by three questions:
- How can we make the web competitive with proprietary and native news consumption experiences on mobile?
- How can we do that while ensuring freedom of branding and monetization for the publisher?
- And how can we not only make these things possible, but really ensure that a broad range of publishers are successful?
The last question was really key: It had always been possible to achieve great user experience on the web–it was just not evenly distributed. This new approach would be about democratizing great experience: enable all publishers no matter their size, technical capabilities, or budget to ship highly performant web pages, rivaling the best pages on the web.
I was lucky that in my previous project at Google, my work had focused on making it easier for engineers to achieve great results without having to be web development experts, which aligns closely with question (3) above. This meant that we could use the internal software developed for this previous work as the basis of the first PCU validator. The crucial insight being that folks don’t need to be experts to achieve a given outcome if a piece of software could instead tell them what to do if they made a mistake.
Our team met with a handful of publishers to test the new format, and dozens more shared their content feeds so we could experiment with it directly on their behalf. We changed the internal PCU name to the AMP Project, or as it was then known, the Accelerated Mobile Pages Project. After countless hours of publisher feedback cycles, we announced our first developer preview in October of 2015 with more than 30 publishers taking part, underscoring our belief that the success of this effort lay not in the leadership of one but in the leadership of many.
Based on feedback from publishers, AMP was designed to:
- Retain maximum branding and user experience flexibility for publishers,
- Support publishers’ business models without disintermediation by a platform,
- Sustain publishers’ access to data,
- All while matching the user experience of closed platforms and introducing innovations like privacy-preserving instant-loading content.
We made AMP open source because we wanted to create a feedback loop with publishers and the web ecosystem. Alternative content delivery frameworks offered publishers a way to deliver content quickly and with a consistent user experience, but were limited in that they were each only applicable to one platform. Our goal was to improve the web as a whole by improving the content experiences of the publishers we were collaborating with. AMP’s earliest versions focused on enabling publishers to create mainly static content pages featuring text, images, and videos. Because of the important role that ads played in determining performance, the developer preview provided basic ad support, with plans to expand quickly to accommodate more complex ad setups and additional monetization models.
The early days: Listen, learn, and repeat
After launching AMP’s developer preview, we were happy to see thousands of publishers from around the world express interest in the initiative. While we were encouraged by the response, we also knew that AMP had a long way to go. Developing a new framework that was compatible with existing publisher business models meant continued work to understand publisher needs, involving many hours spent understanding analytics setups, advertising strategies, and paywall implementations.
As interest in the project grew, we set up regular working groups where publishers could work with Google product managers and engineers on some of AMP’s most requested features, such as amp-analytics or paywall support. In addition to publishers, we also needed to engage with advertising tech and analytics providers, as they are intrinsically linked to publishers’ online business models. More and more ad networks added support for AMP over time: Today 240 different ad networks and 80 analytics providers support AMP.
Over the course of AMP’s first few years in the wild, we continued to collaborate with the various parties involved in the web ecosystem and made significant progress on addressing some of AMP’s biggest gaps. In 2016 we announced the AMP For Ads project, which tackled some of the feedback we heard from publishers about slow ads performance on their web pages. We introduced support for live-blogs that same year, which addressed a key early-stage publisher request to have AMP support more dynamic content experiences.
How criticism made AMP better
While we made a ton of progress in our first few years working on AMP, that progress was not without criticism. This criticism largely fell into two camps: concerns about the AMP URL and its potential impact on publisher traffic, and the AMP requirement for publishers to be eligible to appear in the Top Stories feature in Google Search. While we may not have gotten everything about AMP perfect on the first try, we always aimed to do what was best for the web with the tools available, and worked closely and diligently with publishers and users to evolve AMP to be better.
The URL challenge was complex. We wanted to achieve privacy-preserving instant-loading on the web, and based on the state of the the web platform available to us at this time used iframe-based loading, which led to the suboptimal google.com/amp/www.publisher.com/-shaped URLs. We would have loved to achieve the same user experience without making any changes to URLs, but as is common with larger software projects, we faced a trade-off, in this case between great UX and an undesirable URL format.
To address the issue, we quickly connected with browser vendors to make sure that sharing URLs from AMP experiences would share the canonical URL of the document instead. While this didn’t address the issue at the core, it provided a good solution for one of the core use cases of URLs: When a user shared an AMP document, it would always feature the publisher URL. In parallel we looked for a longer-term solution and worked closely with the web standards community. This work culminated in a technology called signed exchanges, which launched for AMP in Google Search in April of 2019 providing privacy-preserving instant-loading under the publisher URL.
Another point of criticism around AMP was that it was a required technology to participate in the Top Stories Carousel feature in Google Search. Top Stories was designed to provide users with an equally compelling news experience as other quick-consumption, UX-focused formats. We expected users would engage with more news articles, and they did. Over time we heard from developers that they’d rather have choices beyond AMP to participate in this feature, so in 2018 we set out to bring everything we learned from AMP to the rest of the web by establishing web-standards for the things we’d built on the application layer. This work culminated in Google’s recent announcement around page experience signals that provides a path to make all web content eligible for inclusion in the Top Stories Carousel.
Governance changes
In its first two years, AMP grew from a tiny open source project with just two contributors to a much larger one with over 700 individuals contributing over 10,000 commits running on many millions of websites. AMP was governed like many other open-source projects at the time, where most decisions were de-facto made in the project’s working groups, but the final decision making power lay with me, the project creator. As AMP grew, it became clear that this simple governance model was no longer appropriate for an open-source project with such broad impact.
Driven by this insight, the AMP Project proposed a new governance model that moved the power to make significant changes to AMP to a Technical Steering Committee, with representatives from a range of other companies that have committed resources to building AMP. A separate Advisory Committee was established to represent many of AMP’s other constituencies, such as the publishers and platforms who use AMP. AMP Working Groups became more officially established to focus on certain aspects of AMP such as UI, infrastructure, accessibility, etc., and these groups had a clear mechanism for input in the decision making process. This proposal went into effect in November of 2018.
Later that year, AMP announced its intention to move to a foundation, a decision we made after looking at the governance practices of other successful open source projects like Node.js and Kubernetes. Moving to a foundation offers projects like AMP the independence to maintain their own identities, technical focus and product direction while receiving key support services such as marketing support, legal support and more. After considering many options, the OpenJS Foundation stood out as an ideal home for AMP.
Engaging developers: A global community
The AMP Project would not be near where it is today without the support and contributions of the AMP community. In just its first year, AMP saw over 170 contributors push code to the AMP Project repositories. Today, AMP has over 1,100 individual contributors, the vast majority of whom are non-Googlers. At the annual AMP Contributor Summit, we’ve met face-to-face with the hundreds of developers who form a part of our open-source community. This year, we’re participating for the first time in OpenJS’s Collaborator Summit as AMP further integrates itself into the OpenJS Foundation.
The AMP team has also had the opportunity to connect with developers and partners from around the world at our annual AMP Conf. With past locations including New York, Amsterdam, and Tokyo, we’ve met thousands of AMP enthusiasts in-person and over our livestream, sharing the latest and greatest about the future of AMP. In 2018 and 2019 we also hit the road with the AMP Roadshow, which gave interested developers from cities as far-reaching as Seoul, Lagos, Munich, Jakarta and more the chance to attend a free day-long conference to help them get started with AMP.
Unfortunately, we had to postpone AMP Conf and AMP Roadshows this year due to the global pandemic, but we look forward to connecting with the AMP community in other ways in the future.
To the future: Expanding beyond AMP
What started off as a small open-source project in 2015 has grown to be a framework powering nearly 10 billion pages online. With a large, engaged community of contributors, we’ve tackled websites, ads, stories, and email, opening the door for developers to create beautiful, highly performant experiences on the web. The technology behind AMP unlocked the potential to bring a plethora of new functionality to the web, ultimately helping to ensure publishers, merchants, and advertisers could invest in new ways of storytelling to reach an ever-changing user base. That said, there is more work to do to make it easier for users to access content, and to support the success of publishers, and we’re excited about the challenges ahead.
Today AMP is in the concluding phases of completing its transition to the OpenJS Foundation, a transition started last year. This long-awaited move continues to strengthen AMP’s open-governance model, and we can’t wait to expand our horizons even further within the foundation. To learn more about what’s in store for AMP, tune into my keynote talk at OpenJS World, a digital conference hosted by the OpenJS Foundation on June 23.
Posted by Malte Ubl, Member of the AMP Technical Steering Committee, Principal Engineer at Google